Vulnerability /Lethality  Server  High  Level  Architecture 
(HLA)  Interface  Control  Document 

by  Geoffrey  C.  Sauerborn 


ARL-MR-0575 


February  2004 


Approved  for  public  release;  distribution  is  unlimited. 


NOTICES 

Disclaimers 

The  findings  in  this  report  are  not  to  be  construed  as  an  official  Department  of  the  Army  position 
unless  so  designated  by  other  authorized  documents. 

Citation  of  manufacturer’s  or  trade  names  does  not  constitute  an  official  endorsement  or 
approval  of  the  use  thereof. 


DESTRUCTION  NOTICE — Destroy  this  report  when  it  is  no  longer  needed.  Do  not  return  it  to  the 
originator. 


Army  Research  Laboratory 

Aberdeen  Proving  Ground,  MD  21005-5066 


ARL-MR-057 5 


February  2004 


Vulnerability  /Lethality  Server  High  Level  Architecture 
(HLA)  Interface  Control  Document 

Geoffrey  C.  Sauerborn 

Weapons  and  Materials  Research  Directorate,  ARL 


Approved  for  public  release;  distribution  is  unlimited.. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and  maintaining  the  data 
needed,  and  completing  and  reviewing  the  collection  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  the  burden, 
to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188),  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  YA  22202-4302. 
Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a  currently  valid 
OMB  control  number. 

PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

The  U.S.  Army  Research  Laboratory  (ARL)  vulnerability/lethality  table  look-up  server  has  gone  through  several  iterations  of 
development  since  first  introduced  in  1997  (then  as  the  distributed  interactive  simulation  [DIS]  lethality  communications  server). 
These  development  iterations  represented  migration  from  its  original  transmission  control  protocol/internet  protocol  client/server 
communication  form  based  in  DIS,  to  a  combined  DIS-high  level  architecture  (HLA)  form  used  during  the  2001  Research, 
Development,  and  Engineering  Center  (RDEC)  Federation  “CalEx”  (calibration  experiments)  and  onto  this  current  form  that  is 
all  HLA  and  was  designed  for  the  RDEC  command  “IstApp”  (First  Application)  experiment  2003  and  presented  in  this  report. 

This  interface  control  document  (ICD)  describes  the  current  state  of  exposed  interface  control  components  of  the  ARL 
vulnerability/lethality  table  look-up  server  (the  server).  The  ICD  describes  the  interface  to  an  existing  implementation  of  the 
server  (with  its  look-up  table  capability).  The  interface  described  in  this  report  includes  an  area  that  provides  for  further 
expansion,  allowing  delivery  of  damage  descriptions  from  near  real-time  physics-based  vulnerability  models  (future  dynamic 
calculation  capability). 

15.  SUBJECT  TERMS 

distributed  modeling  and  simulation;  high  level  architecture;  HLA;  vulnerability/lethality  server 

17.  LIMITATION  18.  NUMBER 
OF  ABSTRACT  OF  PAGES 

c.  THIS  PAGE  UL  20 

Unclassified _ 

Standard  Form  298  (Rev.  8/98) 
Prescribed  by  ANSI  Std.  Z39.18 


19a.  NAME  OF  RESPONSIBLE  PERSON 

Geoffrey  C.  Sauerbom 

19b.  TELEPHONE  NUMBER  (Include  area  code) 

410-278-8657 


16.  SECURITY  CLASSIFICATION  OF 
a.  REPORT  b.  ABSTRACT 

Unclassified  Unclassified 


1.  REPORT  DATE  (DD-MM-YYYY)  2.  REPORT  TYPE 

February  2004  Final 

4.  TITLE  AND  SUBTITLE 

Vulnerability/Lethality  Server  High  Level  Architecture  (HLA)  Interface 
Control  Document 

6.  AUTHOR(S) 

Geoffrey  C.  Sauerborn  (ARL) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

U.S.  Army  Research  Laboratory 
Weapons  &  Materials  Research  Directorate 
Aberdeen  Proving  Ground,  MD  21005-5066 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


3.  DATES  COVERED  (From  -  To) 

5a.  CONTRACT  NUMBER 
5b.  GRANT  NUMBER 
5c.  PROGRAM  ELEMENT  NUMBER 
5d.  PROJECT  NUMBER 

621618H80 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

ARL-MR-0575 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 


11 


Contents 


List  of  Figures  iii 

List  of  Tables  iii 

1.  Introduction  1 

2.  Scope  1 

3.  Simulation  Object  Model  (SOM)  Intent  1 

3.1  SOM  Object  Classes .  2 

3.2  SOM  Interaction  Classes .  2 

3.3  Assumptions .  4 

4.  References  10 

Distribution  List  1 1 


List  of  Figures 


Figure  1.  Query  and  response  interaction .  3 

Figure  2.  Resulting  damage  interaction .  4 


List  of  Tables 


Table  1.  Lethality  server  class  structure .  2 

Table  2.  Object  classes  (server  published) .  2 

Table  3.  Ancillary  but  required  object  classes  (from  RPR  FOM) .  2 

Table  4.  Lethality  server  interaction  class  structure .  3 

Table  5.  Lethality  server  interaction:  “service.broadcastinfo. lethality .tablelookup” ..  .  5 

Table  6.  Lethality  server  interaction:  “service.query.lethality.tablelookup.parameters”  .  6 

Table  7.  Lethality  server  interaction:  “service. query.lethality.tablelookup.results”  ....  7 

Table  8.  RPR  FOM  interactions .  8 

Table  9.  Enumerations .  8 

Table  10.  Complex  data  types .  8 

iii 


Intentionally  left  blank 


IV 


1.  Introduction 


The  U.S.  Army  Research  Laboratory  (ARL)  vulnerability/lethality  table  look-up  server  has  gone 
through  several  iterations  of  development  since  first  introduced  in  1997  (then  as  the  distributed 
interactive  simulation  [DIS]  lethality  communications  server)  (7).  These  development  iterations 
represented  migration  from  its  original  transmission  control  protocol/intemet  protocol  client/ 
server  communication  form  based  in  DIS,  to  a  combined  DIS-high  level  architecture  (HLA)  form 
used  during  the  2001  Research,  Development,  and  Engineering  Center  (RDEC)  Federation 
“CalEx”  (calibration  experiments)  (2)  and  onto  this  current  form  that  is  all  HLA  and  was 
designed  for  the  RDEC  command  “IstApp”  (First  Application)  experiment  2003  and  presented 
in  this  report  (3, 4, 5, 6). 

This  interface  control  document  (ICD)  describes  the  current  state  of  exposed  HLA  interface 
control  components  of  the  ARL  vulnerability/lethality  table  look-up  server  (the  server).  The  ICD 
describes  the  interface  to  an  existing  implementation  of  the  server  (with  its  look-up  table 
capability).  The  interface  described  in  this  report  includes  an  area  that  provides  for  further 
expansion,  allowing  delivery  of  damage  descriptions  from  near  real-time  physics-based 
vulnerability  models  (future  dynamic  calculation  capability). 


2.  Scope 


The  HLA  specification  requires  an  object  model  template  (OMT).  This  ICD  describes  and 
explains  the  server’s  OMT  object  model  components  (7,  8).  The  server  has  an  HLA  interface. 
HLA  object  model  components  that  are  unique  to  the  server  are  described  in  this  ICD.  Ancillary 
but  required  objects  are  only  mentioned  and  referenced  (all  these  are  from  the  real-time  platform 
reference  federation  object  model  (RPR  FOM)  (9). 


3.  Simulation  Object  Model  (SOM)  Intent 


The  server’s  SOM  is  designed  to  simply  advertise  its  existence  (via  a  small  “service  description” 
object  class  shown  in  table  1);  the  bulk  of  the  SOM  and  work  is  then  conducted  via  HLA 
interactions. 
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3.1  SOM  Object  Classes 

The  idea  behind  this  general  object  class  structure  is  that  a  future  architecture  would  consist  of 
various  “services”.  Thus,  a  “root  service”  should  exist.  “Service”  fills  this  function.  A 
LethalityServer  as  well  as  other  services  would  stem  from  this  node.  MobilityServer  and 
TerrainServer  are  not  used  by  the  LethalityServer.  They  are  only  conceptual  examples  of  other 
services  to  illustrate  this  intended  structure. 


Table  1.  Lethality  server  class  structure 


Classl 

Class2 

Service  (PS) 

i  LethalityServer  (PS) 

i  MobilityServer  (N) 

|  TerrainServer  (N) 

Table  2  names  and  explains  the  variables  (attributes)  within  the  service  class  structure. 
Table  2.  Object  classes  (server  published) 


Object 

Class 

Attribute 

Data  Type 

Attribute  Description 

Service 

(PS) 

Type 

Simulation 

Services 

Enum32 

Name  or  type  of  a  specific  service.  Intent:  There  may  be 
several  services  of  a  particular  class,  each  with  various 
missions  or  degrees  of  fidelity.  “Type”  distinguishes  one  from 
another.  (Type  Example  values:  Lethality Server  Table 

Lookup  (1)  Lethality Server  DynamicCalculation  (2) ).  See 
table  9  Enumerations. 

Service. 

Lethality 

Server 

(PS) 

VersionID 

String 

Revision  control  identifier.  Intent:  The  server  optionally 
accepts  queries  and  delivers  results  based  on  a  conventional 
protocol  configured  to  a  particular  VersionID.  Subscribing 
federates  should  warn  if  the  revision  ID  (VersionID)  is  an 
unexpected  value. 

The  other  object  class  subscribed  to  is  the  BaseEntity.PhysicalEntity  root  from  the  RPR  FOM 
(see  table  3).  The  server  monitors  entity  information  here  to  know  a  target’s  orientation  and 
position  at  the  time  of  munition  detonations. 


Table  3.  Ancillary  but  required  object  classes  (from  RPR  FOM) 


Classl 

Class2 

BaseEntity  [26]  (S) 

PhysicalEntity  (S) 
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3.2  SOM  Interaction  Classes 


The  lethality  server’s  interaction  class  structure  is  shown  in  table  4.  There  is  a  “root  service” 
interaction  class  for  the  same  reason  given  for  the  “root  service  object  class”  (see  table  1).  That 
is,  it  is  a  logical  point  of  entry  for  service-related  interactions. 


Table  4.  Lethality  server  interaction  class  structure 


Intel  action  ! 

Intel  action? 

Interactions 

Intel  action4 

Interactions 

Service  (N) 

Query  (N) 

Lethality  (N) 

TableLookUp  (IS) 

DynamicCalculation  (N)i 

Parameters  (IS) 
i  Result  (IS) 
Parameters  (N) 
i  Result  (N) 

Broadcastlnfo  (N) 

Lethality  (N) 

TabieLookUp  (IS) 
DynamicCalculation  (N)| 

!Resuit'(IS) . 

Result  (N) 

The  general  concept  of  this  interaction  class  structure  is  to  embody  the  rudiments  of  a  query- 
response  mechanism.  This  query-response  is  portrayed  in  figure  1 . 


In  general,  most  of  the  time,  the  server  is  broadcasting  damage  resulting  from  some  event.  It 
does  so  by  sending  interaction  data  along  the  Service.Broadcastlnfo.Lethality  interaction 
hierarchy  object  structure,  namely,  InteractionRoot.Service.Broadcastlnfo.Lethality.Table 
LookUp.Result.  Subscribers  to  this  interaction  will  receive  a  notification  for  every  event  that 
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could  cause  damage.  Currently,  the  only  event  triggering  a  Lethality.TableLookUp.Result 
interaction  is  the  RPR  FOM  “MunitionDetnonation”  interaction.  This  is  portrayed  in  figure  2, 
and  table  5  names  and  explains  the  variables  (parameters)  within  the  Service.Broadcast 
Info.Lethality.TableLookUp  interaction  object  structure. 


3.3  Assumptions 

•  Receiving  applications  are  expected  to  locally  filter  the  messages  based  on  their 
interest.  This  is  because  all  results  are  broadcast.  Only  a  tiny  fraction  of  these  will  apply  to  any 
one  entity  (unless  that  entity  is  very  unlucky). 

•  Affected  entities  are  expected  to  logically  “OR”1  the  resulting  damage  with  their 
current  damage  state.  This  is  because  the  currently  implemented  server  does  not  use  an  entity’s 
current  state  when  calculating  damage.  (This  is  because  the  underlying  look-up  tables  generally 
assume  damage  on  a  “first  hit”  basis.)  The  result  is  that  it  is  possible  to  receive  a  mobility- 
firepower  kill  (MF-Kill)  followed  by  a  second  shot  delivering  a  mobility  kill  (M-Kill).  If  the 
entity  were  to  blindly  follow  the  server,  its  overall  state  would  improve  after  the  second  shot! 

'That  is,  entities  are  expected  to  combine  a  new  damage  state  with  their  existing  state. 
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Table  5.  Lethality  server  interaction:  “service.broadcastinfo. lethality. tablelookup”  (server  published) 


Interaction 

Object 

Parameter 

Data 

Type 

Parameter  Description 

Service. 

Broadcast 

Info. 

Lethality. 

Table 

LookUp 

Event 

[Identifier] 

ID 

Event 

Identifier 

Struct 

An  ID,  generated  by  the  issuing  federate,  used  to  associate  related  fire 
and  detonation  events.  This  ID  identifies  the  detonation  event  whose 
results  are  about  to  be  broadcast  by  the  server.  The 
“EventldentifierStruct”  data  type  is  reused  from  the  RPR  FOM. 

Service. 

Broadcast 

Info. 

Lethality. 

Table 

LookUp 

DISevent 

Identifier 

ID 

DISEvent 

Identifier 

Struct 

The  DIS  event  identifier  record.  This  is  the  triple  unsigned  short  used 
to  identify  events  in  the  DIS  (IEEE  1278)  specification.  It  is  here  for 
DIS  backward  compatibility.  If  a  querying  federate  is  able  to  deter¬ 
mine  the  DIS  event  (i.e.,  if  it  is  monitoring  raw  DIS  traffic  as  well  as 
HLA  traffic),  then  this  field  could  be  useful  to  a  subscribing  federate. 
However,  there  is  no  guarantee  that  the  server  too  is  able  to  monitor 
raw  DIS  traffic.  If  DIS  traffic  is  monitored,  the  server  will  do  its  best 
to  reconstruct  the  event  ID;  however,  as  different  DIS-HLA  gateways 
translate  RPR  FOM  EventIDs  to  the  “DIS  Triple,”  there  can  be  no 
guaranteed  linkage  between  the  DISeventID  and  Eventldentifier  ID 

Service. 

Broadcast 

Info 

Lethality. 

Table 

LookUp. 
Result  (PS) 

Instan¬ 

taneous 

Damage 

Damage 

Status 

Enum32 

This  is  the  instantaneous  result  of  the  subject  damage  event  provided 
by  the  lethality  server.  It  contains  the  results  of  the  damage  event 
(identified  by  TableLookUp.EventID)  against  the  target  (identified  by 
TableLookup.Result.EntitylD).  Results  are  “instantaneous”  because 
they  are  not  cumulative  (server  contains  no  “memory”  of  the  previous 
damage  state)  and  they  might  not  be  repeatable.  The  simulating  entity 
must  logically  “or”  this  damage  result  with  its  previous  damage  state. 

EntitylD 

Entity 

Identifiers 

truct 

The  ID  of  the  entity  being  analyzed  for  vulnerability  to  the  subject 
damage  event  (this  damage  event  is  identified  by 
TableLookup.EventldentifierlD). 

The  “EntityldentifierStruct”  is  reused  from  the  RPR  FOM. 

Entity 

Type 

Entity 

Type 

Struct 

This  is  the  type  identifier  for  the  entity  that  is  under  threat.  (Note:  this 
information  might  be  indirectly  available  via  the  EventldentifierlD 
parameter  but  is  supplied  here  for  convenience.) 

Threat 

Type 

Entity 

Type 

Struct 

The  type  of  munition  or  damage  device  used  to  attack  the  threatened 
entity.  (As  with  “EntityType,”  this  is  provided  for  convenience  and  to 
avoid  ambiguity.) 

Error 

Boolean 

If  TRUE,  then  a  valid  look-up  table  or  other  data  source  could  not  be 
retrieved,  and  the  results  shown  in  the  “InstantaneousDamage” 
parameter  therefore  have  NO  validity.  If  FALSE,  then  a  data  source 
was  found  and  no  other  errors  were  detected.  (See  the  parameter 
ErrorMessage.) 

Error 

Message 

String 

If  an  error  occurred  (parameter  “Error”  =  TRUE)  then  this  field  may 
(or  may  not)  supply  a  helpful  error  message  in  human  readable  text. 

Results 

Flag 

LethalityV 

alue 

FlagEum3 

2 

Tells  more  about  the  instantaneous  result  returned  from  a  lethality 
query  (or  broadcast)  interaction.  By  default,  the  server  always  returns 
a  result  from  a  query,  but  whenever  ResultsFlag  has  any  value  other 
than  “SuccessNoError,”  then  that  result  is  erroneous.  This  flag’s 
returned  value  can  provide  hints  as  to  the  error’s  source.  (See 
ResultsFlagText.) 

Results 

FlagText 

String 

Provides  a  very  short  text  description  of  the  results  flag.  (Basically, 
this  is  the  text  representation  of  the  “ResultsFlag”  enumerated 

Lethality ValueFlagEnum3 2  value.) 
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The  “Service. Query.Lethality.TableLookUp.Parameters”  interaction  class  is  where  federates 
may  query  a  lethality  server  for  more  specific  information.  A  federate  makes  its  query  by 
issuing  this  interaction.  The  server  responds  by  finding  the  results  based  on  the  passed 
interaction  parameters  and  returns  the  results.  Table  6  names  and  explains  these  parameters. 

The  Service.Query. Lethality. TableLookUp.Results  is  the  area  where  results  of  the  table  look-up 
query  are  provided.  Table  7  describes  these  returned  parameters.  The  type  of  results  returned 
depends  on  what  was  queried  (See:  Service.Query.Lethality.TableLookUp.Parameters,  table  6). 


Table  6.  Lethality  server  interaction:  “service. query. lethality .tablelookup.parameters”  (server  subscribed) 


Interaction 

Object 

Parameter 

Data  Type 

Parameter  Description 

Service. 

Query. 

Lethality. 

TableLookUp 

Event 

IdentifierlD 

Event 

Identifier 

Struct 

An  ID  generated  by  the  issuing  federate,  used  to  associate  related 
fire  and  detonation  events.  This  is  the  identifier  that  identifies  a 
detonation  event  and  is  the  subject  of  the  lethality  query. 

DISevent 

IdentifierlD 

DISEntity 

Identifier 

Struct 

The  DIS  event  identifier  record.  This  is  the  triple  unsigned  short 
used  to  identify  events  in  the  DIS  (IEEE  1278)  specification.  If  a 
querying  federate  is  able  to  determine  the  DIS  event  (i.e.,  if  it  is 
monitoring  raw  DIS  traffic  as  well  as  HLA  traffic),  then  this  field 
could  be  filled.  However,  there  is  no  guarantee  that  the  server  is 
able  to  monitor  raw  DIS  traffic;  thus,  an  error  might  be  returned 
in  the  “Query.Lethality.Tablelookup. Result”  interaction  response. 

Service. 

Query. 

Lethality. 

TableLookUp 

.Parameters 

EntitylD 

Event 

Identifier 

Struct 

The  ID  of  the  entity  being  analyzed  for  vulnerability  to  the 
subject  damage  event  (this  damage  event  is  identified  by 
TableLookup.EventldentifierlD). 

Query  ID 

string 

An  identifier  provided  by  the  querying  federate.  This  identifier  is 
returned  with  the  query  result  in  the  TableLookup.Result.QuerylD 
field. 

Special 

Query 

Parameters 

Query 

Lethality 

Table 

Lookup 

Special 

Parameters 

Struct 

This  data  structure  is  used  to  query  the  server  for  many  types  of 
information  beyond  the  normal  M,  F,  MF,  K  damage  result.  It 
can  be  used  to  view  the  initial  conditions  used  by  the  server, 
display  raw  probability  distributions  (not  just  the  outcome)  or 
other  information.  If  all  the  client  wants  is  MFK  results,  then 
these  parameters  should  be  set  to  false. 

Table  8  lists  interactions  defined  in  the  RPR  FOM  to  which  the  server  subscribes.  These  are  not 
explained,  only  referenced. 

Enumerated  data  types  and  complex  data  types  developed  for  the  server  are  explained  in  tables  9 
and  10,  respectfully.  Other  enumerations  are  defined  in  the  RPR  FOM:  DamageStatusEnum32, 
WarheadTypel6,  FuseTypeEnuml6,  DetonationResultCodeEnum8,  ForceIdentifierEnum8, 
MarkingEncodingEnum8 ,  EventT ypeEnum32 . 

Table  10  displays  lethality  server-defined  complex  data  types.  When  executing  a  server  query, 
querying  federates  set  the  Boolean  “QueryLethalityTableLookupSpecialParametersStruct. 
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ProbabilityDistributionQuery”  to  TRUE  if  they  wish  to  receive  the  five  floating  point  numbers 
that  represent  the  cumulative  likelihood  of  only  an  M-Kill,  only  a  firepower  kill  (F-Kill),  an 
MF-Kill,  catastrophic  kill  (K-Kill),  and  no  damage.  These  values  are  “additive”  (also  known  as 
thermometer  redistribution).  This  means  that  within  the  set  of  five  returned  values,  the  first 
value  is  the  probability  of  an  M-Kill;  the  second  floating  point  value  returned  is  the  sum  of  M- 
Kill  +  F-Kill;  the  third  value  is  the  sum  of  M-Kill  +  F-Kill  +  MF-Kill,  and  so  forth. 


Table  7.  Lethality  server  interaction:  “service.query.lethality.tablelookup.results”  (server  published) 


Interaction 

Object 

Parameter 

Data  Type 

Description 

Service. 

Query. 

Lethality. 

TableLookup 

.Results. 

Instantane- 

ousDamage 

Damage 

StatusEnum 

32 

This  is  the  instantaneous  result  of  the  subject  damage  event 
provided  by  the  lethality  server.  It  contains  the  results  of  the 
damage  event  (identified  by  TableLookUp.EventID)  against  the 
target  (identified  by  TableLookup. EntitylD).  Results  are 
“instantaneous”  because  they  are  not  cumulative  (the  server  does 
not  consider  the  previous  entity’s  state  when  issuing  damage  from 
a  new  detonation),  and  the  damage  may  not  be  repeatable.  That 
is,  repeated  calls  for  the  same  detonation  event  can  result  in 
different  outcomes  (albeit  drawn  from  the  same  distribution  of 
outcomes). 

Query  ID 

string 

An  identifier  returned  by  the  server.  This  identifier  was 
originally  provided  by  the  querying  federate  along  with  the  query 
in  the  Service. Query.TableLookup. Parameters. QuerylD  field. 

The  server  returns  the  same  value  placed  by  the  querying  federate 
so  that  the  federate  may  know  the  supplied  result  is  in  response  to 
his  query  and  not  another’s. 

Error 

Boolean 

If  TRUE,  then  a  valid  look-up  table  or  other  data  source  could  not 
be  retrieved  and  the  results  shown  in  the  “InstantaneousDamage” 
parameter  therefore  have  NO  validity.  If  FALSE,  then  a  data 
source  was  found  and  no  other  errors  were  detected.  (See  the 
parameter  ErrorMessage.) 

Error 

Message 

string 

If  an  error  occurred  (parameter  “Error”  =  TRUE),  then  this  field 
may  (or  may  not)  supply  a  helpful  error  message  in  human 
readable  text. 

ResultsFlag 

Lethality 

ValueFlag 

Eum32 

Tells  more  about  the  instantaneous  result  returned  from  a  lethality 
query  (or  broadcast)  interaction.  By  default,  the  server  always 
returns  a  result  from  a  query,  but  whenever  ResultsFlag  has  any 
value  other  than  “Success  NoError,”  then  that  result  is  erroneous. 
This  flag’s  returned  value  can  provide  hints  as  to  the  error’s 
source.  (See  ResultsFlagText.) 

ResultsFlag 

Text 

string 

Provides  a  very  short  text  description  of  the  results  flag. 

(Basically,  this  is  the  text  representation  of  the  “ResultsFlag” 
enumerated  Lethality ValueFlagEnum3 2  value;  see  table  9 
Enumerations.) 
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Table  8.  RPR  FOM  interactions  (server  subscribed) 


Interaction  Object 

How  Used 

Reference 

MunitionDetonation 

1 . )  Server  records  internally. 

2. )  Triggers  server  to  broadcast  the  resulting  damage  (Broadcastlnfo. 

Lethality .  T  ableLookUp  .Result) . 

RPR  FOM 

WeaponFire 

1)  Server  records. 

2)  Under  certain  circumstances,  server  may  use  some  of  this  information  to 
calculate  MunitionDetonation  damage  (e.g.,  to  resolve  ambiguities  in  the 
range  a  munition  was  fired  from). 

RPR  FOM 

Table  9.  Enumerations 


Identifier 

Enumerator 

Representation 

SimulationServicesEnum32 

LethalrtySer  ver_T  ableLookup 

1 

LethalityServer_DynamicCalculation 

2 

T  errainServer_DataPointQueries 

3 

SerialNumberGenerator 

4 

1  LethalrtyValueFlagEnum32 

Success_NoError 

o . 

Error_Unknown 

1 

Error_NoLookupT  ableFound 

2 

Error  jCurruptTable 

3 . 

Error_MissingEnvironmentData 

4 

If  a  querying  federate  wishes  to  examine  all  initial  conditions  used  to  determine  the  vulnerability 
calculation,  then  “QueryLethalityTableLookupSpecialPareamtersStruct.InitialConditionsQuery” 
is  set  TRUE.  The  server  then  will  return  an  ASCII  (American  Standard  Code  for  Information 
Interchange)  human  readable  list  of  its  internal  parameter  values  used  for  the  subject  detonation 
event.  See  “DISEventldentifierlD”  in  table  6  for  an  explanation  of  the  DISEventldentifierStruct. 
Complex  data  types  defined  for  use  by  the  server  are  shown  in  table  10. 


Table  10.  Complex  data  types 


Complex  Datatype 

Field  Name 

Datatype 

Cardinality 

GueryLethalityTableLookupSpecialParametersStruct 

ProbabilityDistributionQuery  j 

boolean 

1 

InitialConditionsQuery 

boolean 

1 

GueryLethalityTableLookupSpecialResult  Struct 

Probability  DistributionMFK 

float 

is . 

InitialConditions 

string 

1 

DISEventldentifierStruct 

host 

unsigned  sho 

1 

application 

unsigned  sho 

1 

eventjd 

unsigned  sho 

1 

Other  server-used  complex  data  types  are  defined  in  the  RPR  FOM:  EventldentifierStruct,  Entity 
IdentifierStruct,  EntityTypeStruct,  RTIObjectldStruct,  RelativePositionStruct,  Velocity Vectors  tract, 
WorldLocationStruct,  MarkingStruct,  OrientationStruct,  and  AccelerationVectorStruct. 
AngularVelocity Vectors truct  and  ArticulatedParameterS tract  are  currently  not  used. 
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